Metadata storage for placeholders in a storage virtualization system

ABSTRACT

A file system executing on a computing device may store a placeholder for a file on secondary storage of the computing device. The placeholder may comprise a sparse data stream containing none or some of the data of the file and information which enables the remotely stored data of the file to be retrieved from the network. As some or all of the data for the file is being stored remotely, the computing device may rely on a storage virtualization provider to create metadata for the file. Thus, the file system executing on the computing device may receive, from the storage virtualization provider, a request to store metadata associated with the file. In response to this request, the file system may store the metadata as a Binary Large Object (BLOB) in a secondary data stream of the placeholder for the file.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 15/848,519, filed on Dec. 20, 2017, now U.S. Pat.No. 11,507,534, which claims the benefit of U.S. Provisional PatentApplication No. 62/504,767 filed on May 11, 2017, titled “MetadataStorage For Placeholders In A Storage Virtualization System,” thecontent of all is hereby incorporated by reference in their entirety.

BACKGROUND

With the ever increasing need for data storage in computer systems, theuse of cloud storage providers is increasing. With cloud storage, thedata of a file or directory is stored “in the cloud” rather than on auser's local computing device. When the data for a file or directory isneeded, it can be pulled “from the cloud” back onto the user's localcomputing device. In a typical computer system, a component located on acomputing device, such as an indexer, may be configured to indexproperties associated with the files and to store these properties asmetadata with the file. Unfortunately, the process of creating andstoring metadata for files stored in the cloud is not as seamless aswhen those files are stored locally on the computing device.

SUMMARY

Disclosed herein are techniques that allow metadata for a file to bereceived from a storage virtualization provider, or any otherapplication, module, or component desiring to store metadata for a filehosted by a storage virtualization provider, and to have that metadatabe stored within a placeholder for the file on the secondary storage ofthe local computing device. For example, in a storage virtualizationsystem, the data of a file may be stored remotely, such as on a network(i.e., in the cloud), and access to the data of the file byapplications, modules, or components of a local computing device may behandled by a storage virtualization provider executing on the localcomputing device that is configured to retrieve the remotely stored dataof the file as needed. In such a system, a storage virtualization filterof the file system of the computing device may store a placeholder forthe file on secondary storage of the computing device. The placeholderfor the file may comprise a sparse data stream containing none or someof the data of the file and information which enables the remotelystored data of the file to be retrieved from the network, as needed.Although the placeholder may not actually hold any of the data of thefile, the placeholder may appear to applications running on thecomputing device as if the complete file was stored on the secondarystorage. But because some or all of the data for the file is storedremotely and is not present on the local computing device, certainapplications or components on the local computing device that mightotherwise generate metadata for the file—such as an indexer—cannot do sobecause not all of the data of the file resides on the local computingdevice. In the case of certain metadata, for example, the file systemmay need to rely on the storage virtualization provider to generatemetadata associated with the file, since the storage virtualizationprovider manages the full file (i.e., all of its data) on remotestorage. Disclosed herein are methods and apparatus that enableapplications or other entities on a local computing device, such as astorage virtualization provider, to request that metadata for a remotelystored file be stored in association with the file on the localcomputing device. According to the methods and apparatus disclosedherein, in one embodiment, when such a request is received, a storagevirtualization filter of the file system on the local computing devicestores the metadata within the placeholder for the file on the secondarystorage of the computing device. In one embodiment, the file system maystore the metadata as a Binary Large Object (BLOB) in a secondary datastream of the placeholder for the file.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing Summary, as well as the following Detailed Description, isbetter understood when read in conjunction with the appended drawings.In order to illustrate the present disclosure, various aspects of thedisclosure are shown. However, the disclosure is not limited to thespecific aspects discussed. In the drawings:

FIG. 1 illustrates an exemplary computing device, in which the aspectsdisclosed herein may be employed;

FIG. 2 illustrates an example architecture for storage virtualization inaccordance with one embodiment;

FIG. 3A illustrates a regular file, in accordance with one embodiment;

FIG. 3B illustrates a placeholder for a file, in accordance with oneembodiment;

FIG. 3C illustrates a reparse point for a placeholder for a file;

FIG. 4 illustrates further details of an architecture for storagevirtualization in accordance with one embodiment;

FIG. 5 illustrates a process of creating a placeholder for a file, inaccordance with one embodiment;

FIG. 6 illustrates a process of accessing file data for a placeholder,in accordance with one embodiment;

FIG. 7A illustrates example details of the file data access process ofFIG. 6 ;

FIG. 7B illustrates additional example details of the file data accessprocess of FIG. 6 ;

FIG. 8A illustrates a regular directory, in accordance with oneembodiment;

FIG. 8B illustrates a placeholder for a directory, in accordance withone embodiment;

FIG. 8C illustrates a reparse point for a directory placeholder, inaccordance with one embodiment;

FIG. 9 illustrates a process for enumeration of a placeholder directory,in accordance with one embodiment;

FIG. 10 is a diagram of an example directory hierarchy;

FIG. 11 illustrates a process for storing metadata in a secondary datastream of a placeholder for a file;

FIG. 12 shows an example secondary data stream; and

FIG. 13 illustrates a process for creating and storing a Binary LargeObject (BLOB).

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Disclosed herein are techniques that allow metadata for a file to bereceived from a storage virtualization provider, or any otherapplication, module, or component desiring to store metadata for a filehosted by a storage virtualization provider, and to have that metadatabe stored within a placeholder for the file on the secondary storage ofthe local computing device. For example, a file system executing on acomputing device may receive, from a storage virtualization provider orfrom another application, module, or component, a request to storemetadata associated with the file. And in response to this request, thefile system may store the metadata as a Binary Large Object (BLOB) in asecondary data stream of the placeholder for the file.

Example Computing Device

FIG. 1 illustrates an example computing device 112 in which thetechniques and solutions disclosed herein may be implemented orembodied. The computing device 112 may be any one of a variety ofdifferent types of computing devices, including, but not limited to, acomputer, personal computer, server, portable computer, mobile computer,wearable computer, laptop, tablet, personal digital assistant,smartphone, digital camera, or any other machine that performscomputations automatically.

The computing device 112 includes a processing unit 114, a system memory116, and a system bus 118. The system bus 118 couples system componentsincluding, but not limited to, the system memory 116 to the processingunit 114. The processing unit 114 may be any of various availableprocessors. Dual microprocessors and other multiprocessor architecturesalso may be employed as the processing unit 114.

The system bus 118 may be any of several types of bus structure(s)including a memory bus or memory controller, a peripheral bus orexternal bus, and/or a local bus using any variety of available busarchitectures including, but not limited to, Industry StandardArchitecture (ISA), Micro-Channel Architecture (MSA), Extended ISA(EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB),Peripheral Component Interconnect (PCI), Card Bus, Universal Serial Bus(USB), Advanced Graphics Port (AGP), Personal Computer Memory CardInternational Association bus (PCMCIA), Firewire (IEEE 1394), and SmallComputer Systems Interface (SCSI).

The system memory 116 includes volatile memory 120 and nonvolatilememory 122. The basic input/output system (BIOS), containing the basicroutines to transfer information between elements within the computingdevice 112, such as during start-up, is stored in nonvolatile memory122. By way of illustration, and not limitation, nonvolatile memory 122may include read only memory (ROM), programmable ROM (PROM),electrically programmable ROM (EPROM), electrically erasable ROM(EEPROM), or flash memory. Volatile memory 120 includes random accessmemory (RAM), which acts as external cache memory. By way ofillustration and not limitation, RAM is available in many forms such assynchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM),double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), SynchlinkDRAM (SLDRAM), and direct Rambus RAM (DRRAM).

Computing device 112 also may include removable/non-removable,volatile/non-volatile computer-readable storage media, which may bereferred to herein as secondary storage. FIG. 1 illustrates secondarystorage, for example, in the form of a disk storage 124. Secondarystorage (e.g., disk storage) 124 includes, but is not limited to,devices like a magnetic disk drive, floppy disk drive, tape drive, Jazdrive, Zip drive, LS-100 drive, memory card (such as an SD memory card),or memory stick. In addition, disk storage 124 may include storage mediaseparately or in combination with other storage media including, but notlimited to, an optical disk drive such as a compact disk ROM device(CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RWDrive) or a digital versatile disk ROM drive (DVD-ROM). To facilitateconnection of the disk storage devices 124 to the system bus 118, aremovable or non-removable interface is typically used such as interface126. The terms disk storage and secondary storage may be usedinterchangeably herein.

FIG. 1 further depicts software that acts as an intermediary betweenusers and the basic computer resources described in the computing device112. Such software includes an operating system 128. Operating system128, which may be stored on disk storage 124, acts to control andallocate resources of the computing device 112. Applications 130 takeadvantage of the management of resources by operating system 128 throughprogram modules 132 and program data 134 stored either in system memory116 or on disk storage 124. It is to be appreciated that the aspectsdescribed herein may be implemented with various operating systems orcombinations of operating systems. As further shown, the operatingsystem 128 includes a file system 129 for storing and organizing, on thedisk storage 124, computer files and the data they contain to make iteasy to find and access them.

A user may enter commands or information into the computing device 112through input device(s) 136. Input devices 136 include, but are notlimited to, a pointing device such as a mouse, trackball, stylus, touchpad, keyboard, microphone, joystick, game pad, satellite dish, scanner,TV tuner card, digital camera, digital video camera, web camera, and thelike. These and other input devices connect to the processing unit 114through the system bus 118 via interface port(s) 138. Interface port(s)138 include, for example, a serial port, a parallel port, a game port,and a universal serial bus (USB). Output device(s) 140 use some of thesame type of ports as input device(s) 136. Thus, for example, a USB portmay be used to provide input to computing device 112, and to outputinformation from computing device 112 to an output device 140. Outputadapter 142 is provided to illustrate that there are some output devices140 like monitors, speakers, and printers, among other output devices140, which require special adapters. The output adapters 142 include, byway of illustration and not limitation, video and sound cards thatprovide a means of connection between the output device 140 and thesystem bus 118. It should be noted that other devices and/or systems ofdevices provide both input and output capabilities such as remotecomputer(s) 144.

Computing device 112 may operate in a networked environment usinglogical connections to one or more remote computing devices, such asremote computing device(s) 144. The remote computing device(s) 144 maybe a personal computer, a server, a router, a network PC, a workstation,a microprocessor based appliance, a peer device, another computingdevice identical to the computing device 112, or the like, and typicallyincludes many or all of the elements described relative to computingdevice 112. For purposes of brevity, only a memory storage device 146 isillustrated with remote computing device(s) 144. Remote computingdevice(s) 144 is logically connected to computing device 112 through anetwork interface 148 and then physically connected via communicationconnection 150. Network interface 148 encompasses communication networkssuch as local-area networks (LAN) and wide-area networks (WAN). LANtechnologies include Fiber Distributed Data Interface (FDDI), CopperDistributed Data Interface (CDDI), Ethernet, Token Ring and the like.WAN technologies include, but are not limited to, point-to-point links,circuit switching networks like Integrated Services Digital Networks(ISDN) and variations thereon, packet switching networks, and DigitalSubscriber Lines (DSL).

Communication connection(s) 150 refers to the hardware/software employedto connect the network interface 148 to the bus 118. While communicationconnection 150 is shown for illustrative clarity inside computing device112, it may also be external to computing device 112. Thehardware/software necessary for connection to the network interface 148includes, for exemplary purposes only, internal and externaltechnologies such as modems including regular telephone grade modems,cable modems and DSL modems, ISDN adapters, and Ethernet cards.

As used herein, the terms “component,” “system,” “module,” and the likeare intended to refer to a computer-related entity, either hardware, acombination of hardware and software, software, or software inexecution. For example, a component may be, but is not limited to being,a process running on a processor, a processor, an object, an executable,a thread of execution, a program, and/or a computer. By way ofillustration, both an application running on a server and the server maybe a component. One or more components may reside within a processand/or thread of execution and a component may be localized on onecomputer and/or distributed between two or more computers.

Storage Virtualization

In accordance with the storage virtualization techniques disclosedherein, a placeholder may be created on a local computing device for afile or directory. The placeholder appears to a user or application as aregular file or directory on the computing device. That is, anapplication can issue I/O calls on the file or directory as if the fileor directory was stored locally, but the placeholder may not contain allthe data of the file or directory. FIG. 2 is a block diagramillustrating the components of an architecture for implementing thestorage virtualization techniques described herein, in accordance withone embodiment. As shown, in one embodiment, the architecture comprises:a user-mode storage virtualization provider module 202 responsible forretrieving remotely stored file and directory data from a network 208(e.g., “from the cloud”); a file system filter 204, referred to hereinas a storage virtualization filter, that creates and managesplaceholders for files and directories and notifies the user-modestorage virtualization provider of access attempts to files ordirectories whose data is managed by the filter 204 and provider 202; auser-mode library 206 that abstracts many of the details ofprovider-filter communication; and a shell component 210 that serves asan interface for access to the file system 129 by an application 130 andthe storage virtualization provider 202. Note that while the storagevirtualization provider 202 runs in user-mode in the illustratedembodiment of FIG. 2 , in other embodiments the storage virtualizationprovider 202 could be a kernel-mode component. The disclosedarchitecture is not limited to the user-mode embodiment describedherein.

In the illustrated embodiment, the user-mode storage virtualizationprovider module 202 may be implemented (e.g., programmed) by a developerof a remote storage service or entity that provides remote storageservices to computing device users. Examples of such remote storageservices, sometimes also referred to as cloud storage services, includeMicrosoft OneDrive and similar services. Thus, there may be multipledifferent storage virtualization providers, each for a different remotestorage service. In the illustrated embodiment, the storagevirtualization provider module 202 interfaces with the storagevirtualization filter 204 via application programming interfaces (APIs)defined and implemented by the user mode library 206. The storagevirtualization provider module 202 implements the intelligence andfunctionality necessary to store and fetch file or directory datato/from a remote storage location (not shown) on the network 208.

The user-mode library 206 abstracts many of the details of communicationbetween the storage virtualization filter 204 and the storagevirtualization provider 202. This may make implementing a storagevirtualization provider 202 easier by providing APIs that are simplerand more unified in appearance than calling various file system APIsdirectly. The APIs are intended to be redistributable and fullydocumented for third party's to develop storage virtualization providersfor their remote storage services. Also, by implementing such a library206, underlying provider-filter communication interfaces may be changedwithout breaking application compatibility.

As explained above, the storage virtualization techniques describedherein may be applied to both files and directories in a computingdevice. For ease of illustration only, the operation of these storagevirtualization techniques on files will be explained first, followed byan explanation of the operation of these techniques on directories.

Storage Virtualization for Files

In one embodiment, a file may begin either as a regular file or as aplaceholder. FIG. 3A illustrates an example of a regular file 300. Asshown, a regular file typically contains metadata 302 about the file(e.g., attributes, time stamps, etc.), a primary data stream 304 thatholds the data of the file, and optionally one or more secondary datastreams 306. In contrast, as illustrated in FIG. 3B, in one embodiment,a placeholder 308 comprises: metadata 310 for a file, which may beidentical to the metadata 302 of a regular file 300; a sparse primarydata stream 312 which may contain none or some data of the file (therest of the data being stored remotely by a remote storage provider);information 314 which enables the remotely stored data for the file tobe retrieved; and optionally one or more secondary data streams 316.Because all or some of the data for a file represented by a placeholder308 is not stored as a primary data stream in the file, the placeholder308 may consume less space in the local storage of a computing device.Note that a placeholder can at times contain all of the data of the file(for example because all of it was fetched), but as a placeholder, it isstill managed by the storage virtualization filter 204 and storagevirtualization provider 202 as described herein.

With reference to FIG. 3C, in one embodiment, the information 314 whichenables the remotely stored data for the file to be retrieved comprisesa reparse point 314. As shown, a reparse point is a data structurecomprising a tag 322 and accompanying data 324. The tag 322 is used toassociate the reparse point with a particular file system filter in thefile system stack of the computing device. In the present embodiment,the tag identifies the reparse point as being associated with thestorage virtualization filter 204. In one embodiment, the data 324 ofthe reparse point 314 may comprise a globally unique identifier (GUID)associated with the storage virtualization provider 202—to identify thestorage virtualization provider 202 as the provider for the actual filedata for the placeholder. In addition, the data 324 may comprise anidentifier of the file itself, such as a file name or other fileidentifier.

In one embodiment, placeholders do not contain any of the file data.Rather, when there is a request to access the data of a file representedby the placeholder, the storage virtualization filter 204 must work withthe storage virtualization provider 202 to fetch all of the file data,effectively restoring the full contents of the file on the local storagemedium 124. However, in other embodiments, partial fetches of data areenabled. In these embodiments, some extents of the primary data streamof a file may be stored locally as part of the placeholder, while otherextents are stored and managed remotely by the storage virtualizationprovider 202. In such embodiments, the data 324 of the reparse point ofa placeholder may contain a data structure, such as an “on-disk” bitmap,that identifies extents (i.e. chunks) of the file that are storedlocally versus those that are stored remotely. In one embodiment, suchan on-disk bitmap may comprise a sequence of bits, where each bitrepresents one 4 KB chunk of the file. In other embodiments, each bitmay represent a different size chunk of data. In one embodiment, a bitis set if the corresponding chunk is already present in the localstorage. As described hereinafter, when a request to read an extent of afile represented by a placeholder is received, the storagevirtualization filter 204 examines the on-disk bitmap to determine whatparts of the file, if any, are not present on the local storage. Foreach range of a file that is not present, the storage virtualizationfilter 204 will then request the virtualization provider 202 to fetchthose ranges from the remote storage.

FIG. 4 is a block diagram of the storage virtualization architecture ofFIG. 2 , as embodied in a computing device that implements the MicrosoftWindows operating system and in which the file system 129 comprises theMicrosoft NTFS file system. It is understood that the architectureillustrated in FIG. 4 is just one example, and the aspects of thestorage virtualization solution described herein are in no way limitedto implementation in this example environment. Rather, the aspectsdisclosed herein may be implemented in any suitable operating system andfile system environment.

As shown in FIG. 4 , an application 130 may perform file operations(e.g., create, open, read, write) by invoking an appropriate I/O callvia the Win32 API 402 of the Windows operating system. These I/O callswill then be passed to an I/O Manager 404 in the kernel space of theoperating system. The I/O Manager will pass the I/O call to the filesystem's stack, which may comprise one or more file system filters.Initially, the call will pass through these filters to the file system129 itself. In the case of Microsoft's NTFS reparse point technology, ifthe file system accesses a file on disk 124 that contains a reparsepoint data structure, the file system will pass the I/O request back upto the stack 406. A file system filter that corresponds to the tag(i.e., globally unique identifier) of the reparse point will recognizethe I/O as relating to a file whose access is to be handled by thatfilter. The filter will process the I/O and then pass the I/O back tothe file system for proper handling as facilitated by the filter.

In the case of placeholder files described herein, the file system willpass the I/O request back up the stack to the storage virtualizationfilter 204, which will handle the I/O request in accordance with themethods described hereinafter.

With continued reference to FIG. 4 , FIG. 5 is a flow diagramillustrating the steps performed by the storage virtualization filter204 in order to create a placeholder for a file, in accordance with theexample architecture illustrated in FIG. 4 . The process may beinitiated by the storage virtualization provider 202, which may call aCreatePlaceholders function of the user-mode library 206 to do so. Thelibrary 206 will, in turn, convert that call into a correspondingCreatePlaceholders message to the storage virtualization filter 204,which will receive that message in step 502 of FIG. 5 . Next, inresponse to the CreatePlaceholders message, the storage virtualizationfilter 204 will create a 0-length file that serves as the placeholder,as shown at step 504. The CreatePlaceholders message will contain a filename for the placeholder, given by the storage virtualization provider202. In step 506, the storage virtualization filter 204 will mark the0-length file as a sparse file. In one embodiment, this may be done bysetting an attribute of the metadata of the placeholder. A file that ismarked as a sparse file will be recognized by the underlying file systemas containing a sparse data set—typically all zeros. The file systemwill respond by not allocating hard disk drive space to the file (exceptin regions where it might contain nonzero data).

Continuing with the process illustrated in FIG. 5 , in step 508, thestorage virtualization filter 204 will set the primary data streamlength of the file to a value given by the storage virtualizationprovider 202 in the CreatePlaceholders message. In step 510, the storagevirtualization filter 204 sets any additional metadata for theplaceholder file, such as time stamps, access control lists (ACLs), andany other metadata supplied by the storage virtualization provider 202in the CreatePlaceholders message. Lastly, in step 512, the storagevirtualization filter 204 sets the reparse point and stores it in theplaceholder file. As described above in connection with FIG. 3C, thereparse point comprises a tag associating it with the storagevirtualization filter 204 and data, which may include an identifier ofthe storage virtualization provider 202 that requested the placeholder,the file name or other file identifier given by the storagevirtualization provider 202, and an on-disk bitmap or other datastructure that identifies whether the placeholder contains any extentsof the file data.

Once creation of the placeholder is completed, the placeholder willappear to a user or application (e.g., application(s) 130) as any otherfile stored locally on the computing device. That is, the details of theremote storage of the file data is effectively hidden from theapplications(s).

In order for an application to issue I/O requests on a file, theapplication typically must first request the file system to open thefile. In the present embodiment, an application will issue a CreateFilecall with the OPEN_EXISTING flag set via the Win32 API. This request toopen the file will flow down through the file system stack 406 to thefile system 129. As described above, in the case of a placeholder file,the file system 129 will detect the presence of the reparse point in thefile and will send the request back up the stack 406 where it will beintercepted by the storage virtualization filter 204. The storagevirtualization filter 204 will perform operations necessary to open thefile and will then reissue the request to the file system 129 in amanner that allows the file system to complete the file open operation.The file system will then return a handle for the opened file to therequesting application. At this point, the application 130 may thenissue I/O calls (e.g., read, write, etc.) on the file.

FIG. 6 is a flow diagram illustrating a method for processing an I/Orequest to read all or a portion of a file represented by a placeholder,in accordance with one embodiment. A request to read a file representedby a placeholder may come from an application 130 via the Win32 API 402in the form of a ReadFile call. As shown, in step 602, the ReadFile callwill be received by the storage virtualization filter 204. At step 604,the storage virtualization filter 204 will determine whether therequested range of data for the file is present in the placeholder orwhether it is stored remotely by the storage virtualization provider202. This determination may be made by examining the on-disk bitmapstored as part of the data of the reparse point for the placeholder. Ifthe storage virtualization filter 204 determines that the requestedrange of data is stored locally (for example, because it was fetchedfrom remote storage in connection with a prior I/O request), then instep 606 the storage virtualization filter 204 will pass the ReadFilecall to the file system 129 for normal processing. The file system willthen return the data to the requesting application.

If all or some of the data is not present in the local storage, then instep 608 the storage virtualization filter 204 must formulate one ormore GetFileData requests to the storage virtualization provider 202 tofetch the required data. Reads typically result in partial fetches,while some data-modifying operations may trigger fetching of the fullfile. Once the desired fetch range is determined, the storagevirtualization filter 204 must decide whether to generate a GetFileDatarequest for all, some, or none of the range. Preferably, the filtertries to generate a GetFileData for a particular range only once. So, ifan earlier GetFileData request is outstanding, and another operationarrives whose requested range overlaps the outstanding GetFileDatarequest, the filter 204 will trim the range needed by the secondoperation so that its GetFileData request to the provider 202 does notoverlap the previous request. This trimming may result in no GetFileDatarequest at all. FIG. 7A illustrates this functionality.

As shown in FIG. 7A, a second ReadFile request (“ReadFile 2”) overlaps aprior request (“ReadFile 1”). So, the storage virtualization filter 204trims the request range of the GetFileData request that it generates tothe storage virtualization provider 202. A third ReadFile request(“ReadFile 3”) is fully encompassed by the two prior requests, so thereis no need for the filter 204 to fetch data to satisfy that request. Allthe data requested by ReadFile 3 will have already been fetched inresponse to the previous two requests. Thus, as illustrated, the storagevirtualization filter 204 determines whether any portion of the remotelystored data it needs to retrieve (i.e., the data for which it hasdetermined one or more GetFileData requests is needed) has previouslybeen requested from the storage virtualization provider 202 but not yetreceived, and then if so, it trims any new requests to the storagevirtualization provider so that they do not overlap with any suchpreviously requested but not yet received data.

As illustrated in FIG. 7B, the storage virtualization filter 204 maydetermine which ranges of file data need to be requested from thestorage virtualization provider 202 by examining the on-disk bitmapthat, in one embodiment, is maintained as part of the data of thereparse point of the placeholder. The bitmap is depicted as the middlerectangle in the diagram. Ranges of the file that are already stored ondisk are indicated by the hatched spaces in the bitmap. As mentionedabove, each bit of the bitmap may indicate the status of a correspondingrange (e.g., each bit may represent a corresponding 4 KB range) of thefile represented by the placeholder. As illustrated in FIG. 7B, afterexamining the bitmap, the storage virtualization filter 204 is able todetermine which data can be read from disk and which data is needed fromthe storage virtualization provider 202. The bottom rectangleillustrates the result of comparing the ReadFile request with theon-disk bitmap. The regions the filter will read from disk areindicated, as are the regions the filter will need to obtain from theprovider 202.

In one embodiment, the storage virtualization filter 204 may alsomaintain a tree of in-flight GetFileData requests for each file. Eachentry in the tree records the offset and length of data the filter hasrequested from the provider and not yet received. The tree may beindexed by the file offset. For each region the filter 204 determines isnot yet present, the filter 204 may consult the in-flight tree todetermine whether any of the regions it may need have already beenrequested. This may result in further splitting of the GetFileDatarequests. Once the filter has determined the final set of GetFileDatarequests it needs to send, it may insert the GetFileData requests intothe in-flight tree and sends them to the provider 202.

Referring again to FIG. 6 , the storage virtualization filter 204 willissue any necessary GetFileData requests to the storage virtualizationprovider 202 in step 608. Upon receipt, the user-mode libraryincorporated in the storage virtualization provider 202 will invoke acorresponding GetFileData callback function implemented by the storagevirtualization provider 202. The storage virtualization provider 202will then perform operations necessary to retrieve the requested datafrom remote storage on the network. The storage virtualization provider202 will then return the data to the library 206, and in step 610, therequested file data is returned to the storage virtualization filter204. At this point, there are two alternatives.

In one alternative, the storage virtualization filter issues a WriteFilerequest to the file system 129 requesting that the fetched data bewritten to the data stream of the placeholder. Then, in step 614, thestorage virtualization filter 204 will update the on-disk bitmap toindicate that the particular range(s) of data now resides on disk. Notethat in one embodiment, the storage virtualization filter 204 makes adistinction between unmodified resident data and modified resident data,and this distinction can potentially help with differential syncing ofresident and remote data.

Alternatively, in accordance with another feature of the storagevirtualization solution described herein, instead of writing the fetcheddata to disk, the storage virtualization filter 204 may return therequested data to the application 130 directly, without storing the dataon disk. This may be advantageous in situations where disk space isalready limited. This feature may also be used to implement a form ofdata streaming from the remote storage to the requesting application.

According to another aspect of the storage virtualization techniquesdescribed herein, the storage virtualization filter 204 may alsoinitiate and manage the conversion of a regular file to a placeholder.During this process, a placeholder will be created for the file asdescribed above, and the data of the primary data stream of the regularfile will be sent to the storage virtualization provider 202 for remotestorage on the network. For ease of description only, the method ofconverting a regular file to a placeholder and moving its primary datastream data to remote storage may be referred to as “dehydration,” andthe method of fetching the remotely stored data of a placeholder fromremote storage and writing it back to disk may be referred to as“hydration.”

Storage Virtualization for Directories

The storage virtualization techniques described herein may also beapplied to directories in a manner similar to how files are treated. Inmany file systems, directories are implemented as files themselves. Asillustrated in FIG. 8A, a directory typically comprises metadata 802which provides various information about the directory, such as the nameof the directory, its length, time of creation, and other informationuseful to the file system or an application. In addition to the metadata802, the directory will also contain one or more child directory entries804. Each child entry may represent a file within the directory or asubdirectory of the directory. For example, a child entry for a file maycontain a field that stores attributes associated with the file (such aswhether the file is “read only” or “hidden”), a field that storescharacters of a file name for the file, one or more fields storinginformation indicating the date and time of file creation, a fieldindicating a size of the file, and a field indicating a startinglocation (e.g., starting cluster) on the storage medium where the datafor the file resides. Of course, this is just one example of the formatand contents of a child entry, and it is understood that the formats andcontents of child entries may differ from file system to file system. Achild entry for a subdirectory may comprise similar fields for the filerepresenting the subdirectory. Often a directory is part of a largerhierarchy of directories. The top most directory of such a hierarchy isoften referred to as the root directory.

In accordance with the storage virtualization techniques disclosedherein, a placeholder may be created for a directory. FIG. 8B illustratean example placeholder for a directory. As shown, the placeholder maycomprise a file containing: metadata 808, which may include some or allof the metadata 802 of a full directory; none, some, or all childentries 810 of the directory; and information 812 which enables anyremotely stored child entries for the directory to be retrieved. Becauseall or some of the child entries for a directory represented byplaceholder directory 806 may not be stored in the directory onsecondary storage (e.g., disk 124), the placeholder directory 806 mayconsume less space in the local storage of a computing device.

With reference to FIG. 8C, in one embodiment, the information 812 whichenables the remotely stored child entries for the directory to beretrieved comprises a reparse point 814. As shown, the reparse point 814is a data structure comprising a tag 816 and accompanying data 818. Asdescribed above, the tag is used to associate the reparse point with aparticular file system filter in the file system stack of the computingdevice. In the present embodiment, the tag identifies the reparse pointas being associated with the storage virtualization filter 204. In oneembodiment, the data 818 of the reparse point 814 may comprise aglobally unique identifier associated with the storage virtualizationprovider 202—to identify the storage virtualization provider 202 as theprovider for the actual child entries for the placeholder directory. Inaddition, the data 818 may comprise an identifier of the directoryitself, such as a directory name or other directory identifier.

As in the case of placeholders for files, a storage virtualizationprovider 202 that is maintaining a full directory hierarchy on remotestorage over a network may request that a placeholder be created for adirectory. In the case of directories, however, the storagevirtualization provider 202 may initially request creation of aplaceholder only for the root directory in a remotely stored directoryhierarchy. Then, when an application begins to enumerate that directory,the storage virtualization provider 202 may request the creation ofadditional placeholders for the child directories (i.e., subdirectories)and/or the files under the root directory. As used herein, the phrase“enumerate a directory” and the like refers to a process by which thecontents of a directory, including any files or subdirectories (each ofwhich is represented in the directory by one or more respective childentries), may be examined or retrieved (such as in the form a directorylisting) upon request to the file system of a computing device.

As with the creation of placeholders for files, the storagevirtualization provider 202 can request the creation of a placeholderfor a directory, for example, by calling a CreatePlaceholders functionof the user-mode library 206. In that example implementation, thelibrary 206 will, in turn, convert that call into a correspondingCreatePlaceholders message to the storage virtualization filter 502. Inresponse to the CreatePlaceholders message, the storage virtualizationfilter 204 will create an empty directory (i.e., an empty file) thatserves as the placeholder for the directory. The storage virtualizationfilter 204 may then store in the placeholder directory any additionalmetadata associated with the directory, such as time stamps, accesscontrol lists (ACLs), and other metadata supplied by the storagevirtualization provider 202 in the CreatePlaceholders message. Thestorage virtualization filter 204 will then add to the placeholderinformation which enables any remotely stored child entries of thedirectory to be retrieved from remote storage. In the embodimentillustrated in FIG. 8C, this information may comprise a reparse point.As described above in connection with FIG. 8C, the reparse pointcomprises a tag associating it with the storage virtualization filter204 and data, which may include an identifier of the storagevirtualization provider 202 that requested the placeholder and thedirectory name or other directory identifier given by the storagevirtualization provider 202.

Once creation of the placeholder for the directory is completed, theplaceholder will appear to a user or application (e.g., application(s)130) as a directory stored locally on the computing device. That is, thedetails of the remote storage of the directory is effectively hiddenfrom the applications(s).

The process for enumeration of a directory represented by a placeholderis similar to the process illustrated in FIG. 6 for accessing data of aplaceholder for a file. FIG. 9 illustrates the steps performed by thestorage virtualization filter 204 for directory enumeration, inaccordance with one embodiment. An application will typically initiatedirectory enumeration via, for example, a Win32 API call requiring thedirectory to be enumerated, such as a request to list the contents ofthe directory or a request to access a file having the directory in itsdirectory path. As in the case of files, this I/O call or request willbe passed to the file system 129, which, in the embodiment illustratedherein, will detect the reparse point in the directory placeholder andpass the I/O call back up the file system stack to the storagevirtualization filter 204 for processing.

As shown in FIG. 9 , in one embodiment, the storage virtualizationfilter 204 will begin the process at step 902 by issuing aStartDirectoryEnumeration command to the storage virtualization provider202. Upon receiving this command, the storage virtualization provider202 will establish a context that can be used throughout a set ofenumeration requests for the directory. The StartDirectoryEnumerationcommand will include the pathname from the root of the remotely storeddirectory hierarchy to the directory to be enumerated. In step 906, thestorage virtualization filter will issue a GetDirectoryEntries commandto the storage virtualization provider 202 to request that the storagevirtualization provider 202 fetch (i.e., retrieve) all or some range(e.g., 1 to N) of child directory entries of the directory from theremote storage. In one embodiment, the first GetDirectoryEntries commandmay include a search string, and the storage virtualization provider 202may only fetch the directory entries that match this search string. Thesearch string could be a full file name, e.g. foo.txt or a wild cardname, e.g. foo*. In response to the GetDirectoryEntries command, thelibrary 206 will invoke a corresponding callback function implemented bythe storage virtualization provider 202, which will cause the storagevirtualization provider 202 to fetch the requested entries from theremote storage and return them to the storage virtualization filter 204.In step 908, the storage virtualization filter 204 receives the fetcheddirectory entries from the storage virtualization provider 202. Thereceived entries may then be returned to the requesting application orother entity that may have triggered the enumeration.

In one embodiment, as illustrated in optional step 910, the childentries received in step 908 may be written to the placeholder for thedirectory on the secondary storage (e.g., storage 124) of the computingdevice. This may result in a partial representation of the directory onthe secondary storage. On subsequent enumerations, this may result infaster processing, as the child entries needed to satisfy a subsequentenumeration may actually be stored locally on the secondary storagewithin the placeholder of the enumerated directory. Also, when at leastsome of the child entries of a directory are stored locally on thesecondary storage, the storage virtualization filter 204 may respond toa subsequent enumeration request for the directory by enumerating boththe locally stored child entries and the remotely stored child entriesand then merging the results before returning the enumerated entries tothe requesting application. In one embodiment, in the event of anyconflicting entries during that merging process, the locally storedchild entries may take precedence over the child entries retrieved fromremote storage. That is, if there are versions of the same child entryin both the local storage (e.g., within the directory placeholder on thesecondary storage) and in the remotely stored representation of thedirectory, the locally stored version will be returned to the requestingapplication instead of the version retrieved from remote storage.Alternatively, in other embodiments, a policy may be established bywhich the child entries retrieved from remote storage take precedenceover any locally stored child entries.

Once the enumeration is completed, in one embodiment, the storagevirtualization filter 204 may end the enumeration process by issuing aEndDirectoryEnumeration command to the storage virtualization provider202, and upon receiving this command, the storage virtualizationprovider 202 will free any resource(s), e.g. memory or opened handles,used during the process.

The process of writing fetched child entries to local storage isdifferent for directories than it is for files. As mentioned above, thestorage virtualization provider 202 may initially request creation of aplaceholder directory only for the root directory in a remotely storeddirectory hierarchy. Then, when an application begins to enumerate thatdirectory, the storage virtualization provider 202 may request thecreation of additional placeholders for the child subdirectories and/orthe files under the root. Alternatively, the storage virtualizationfilter 204 may decide whether to create additional placeholders for thechild subdirectories and/or the files under the root. For example, theremotely stored directory hierarchy maintained by the storagevirtualization provider 202 on remote storage may have the hierarchyillustrated in FIG. 10 . As shown, the example hierarchy has a rootdirectory called “foo,” which contains files “1.txt,” “2.txt,” “3.txt”and a subdirectory called “bar.” When the application requests toenumerate the root directory foo, the process described above willreturn the child entries for the files 1.txt, 2.txt, and 3.txt and thechild entry for the subdirectory bar. But at that point, the only itemstored on the secondary storage of the computing device is the directoryfoo. Accordingly, in conjunction with this directory enumeration, thestorage virtualization provider 202 may also then request the storagevirtualization filter 204 to create placeholders for each of the files1.txt, 2.txt, and 3.txt and for the subdirectory bar.

Continuing this example, at this point the on-disk representation of thedirectory hierarchy will include the directory foo, and the placeholdersfor 1.txt, 2.txt, and 3.txt and the subdirectory bar. Suppose that theremotely stored virtualized directory hierarchy further includes a filewith the path foo\bar\foo1\bar1\5.txt and that an application requeststhat file. The storage virtualization filter 204 will need to fetch andcreate placeholders for each of the additional subdirectories foo1 andbar1 as well as the file 5.txt. In accordance with the storagevirtualization techniques disclosed herein, the storage virtualizationfilter 204 can request this all at once or it can be requested in aniterative process.

More specifically, in one embodiment, the storage virtualization filter204 may attach a reparse processing flag to the request so that when theapplication's request for that file reaches the file system, if the lastcomponent of the partial on-disk directory hierarchy representation(“bar” in the example) contains the reparse point tag of the storagevirtualization filter 204, the file system will complete the requestwith STATUS_REPARSE.

In the virtualization filter's handler to this status code, it issues aGetPlaceholderInformation command to the storage virtualization provider202 with the name of the next component relative to the virtualizationroot, e.g., bar\foo1 in the present example. Upon receiving thiscommand, the storage virtualization provider 202 checks if the requestedpath exists in the remote storage, and if yes, the virtualizationprovider 202 returns to the storage virtualization filter 204 theinformation necessary to create a placeholder for foo1. The storagevirtualization filter 204 will then create a file named foo1 under thefoo\bar\ folder that serves as the placeholder for foo1 and set thereparse point on this file, then re-issue the application's request. Thevirtualization filter 204 will repeat the process to have placeholdersfor the components bar1 and 5.txt created. Note that in otherembodiments, instead of the virtualization filter 204 automaticallycreating a placeholder for each component upon receiving from thevirtualization provider 202 the information necessary to create theplaceholder, the virtualization provider 202 may instead request thecreation of a placeholder for each component by calling theCreatePlaceholders function of the user-mode library as it iteratesthrough each component of the path.

After 5.txt is created on the secondary storage, since 5.txt is the lastcomponent in the request, the virtualization filter 204 will clear thereparse processing flag before re-issuing the request. The file system129 will then complete the request with STATUS_SUCCESS this time so thatthe request will complete and return to the application.

Because of the nature of directory enumeration, it is possible that thelocal on-disk representation of a directory hierarchy—usingplaceholders—may not be complete. For example, when enumerating the pathfoo\bar\foo1\bar1\5.txt, placeholders may be created for subdirectoriesfoo1 and bar1 and the file 5.txt. However, it could be the case that thedirectory foo\bar also contains subdirectories foo2 and foo3 (asillustrated in FIG. 10 ). Placeholders may not have been created forthose subdirectories. Thus, the placeholders for the subdirectories foo,bar, foo1, bar1, and 5.txt may form a partial representation of the fulldirectory hierarchy stored remotely on the network. Moreover, it ispossible for an application to make changes to the local on-diskrepresentation. For example, an application may create a new file 6.txtin the directory foo\bar\foo1\bar1. Or the application could delete thefile 5.txt from that directory or rename the file. According to afurther aspect of the storage virtualization techniques describedherein, the storage virtualization filter 204 and storage virtualizationprovider 202 may perform a synchronization operation to ensure that anypartial representation of the directory hierarchy on disk remainssynchronized with the corresponding portion of the full directoryhierarchy on the remote storage.

Because a goal of the storage virtualization techniques disclosed hereinis to hide the details of the remote storage from applications such thatthe existence of directories and files appears to an application as ifthey were all stored and maintained locally, any changes to the on-diskrepresentation by an application should take precedence. Accordingly,when changes are made by the file system in response to a request froman application, such as deleting or renaming a file, a mechanism isneeded to inform the storage virtualization provider 202 during a mergeoperation that such a change has occurred to ensure that otherapplications will not be able to open or see this file in subsequentdirectory enumerations. In accordance with another aspect of the storagevirtualization techniques disclosed herein, the concept of a tombstoneis introduced. A tombstone is information that remains on the secondarystorage of the computer device (e.g., disk 124) after a file ordirectory represented by a placeholder is deleted or renamed by anapplication. In one embodiment, a tombstone may be implemented by a newflag or attribute in the metadata of a placeholder for a file ordirectory that has been deleted. The flag indicates that the file ordirectory has been deleted or renamed, and the storage virtualizationfilter 204 and storage virtualization provider 202 may cooperate toensure that the deletion or renaming represented by the tombstone ismade to the full directory hierarchy on the remote storage whensynchronizing the on-disk and remote storage representations.

Metadata Storage for Placeholders

With reference to FIG. 3A, a regular file may contain metadata 302 aboutthe file (e.g., attributes, time stamps, etc.), a primary data stream304 that holds the data of the file, and optionally one or moresecondary data streams 306. A computing device storing the file may beconfigured to generate the metadata 302 for the file based oninformation contained in the primary data stream 304 of the file. Incontrast, as illustrated in FIG. 3B, a placeholder 308 for a file maycomprises: metadata 310 for the file, which may be identical to themetadata 302 of a regular file 300; a sparse primary data stream 312which may contain none or some data of the file; information 314 whichenables the remotely stored data for the file to be retrieved; andoptionally one or more secondary data streams 316. A computing devicestoring the placeholder for the file 308 may be unable to generatemetadata 302 for the placeholder 308 of the file since the sparseprimary data stream 312 may contain none or only a portion of the dataneeded to generate the metadata 302 about the file. The remainder of thedata of the file needed to generate the metadata 302 may be storedremotely by a remote storage provider.

In an example computing device, such as computing device 112 illustratedin FIG. 4 , an indexer (not shown) may be configured to identifyproperties of files stored on the computing device 112 and to storethose properties in a database on the computing device 112, such as thesecondary storage 124. For example, one type of property stored in thesecondary storage may be properties that are part of the metadata of thefile, such as a time stamp or a size of the file. A second type ofproperty stored in the secondary storage may be properties that can beobtained by reading the contents of the file itself, such as an artistor track length in an example that the file is a music file. Theseproperties may be stored in the secondary storage 124 and laterretrieved by the indexer using a search function of the computing device112. However, when some or all of the data associated with the file isbeing stored remotely by a remote storage provider rather than on thecomputing device itself, the computing device 112 may be unable togenerate the metadata 302 for the given file because the indexer doesnot have access to the contents of the file needed to generate themetadata. Thus, the computing device 112 may need to rely on the remotestorage provider (e.g., storage virtualization provider 202) to generatethe metadata 302.

FIG. 11 illustrates an example method for receiving metadata associatedwith a file whose contents are stored remotely and storing that metadatain the secondary storage of a computing device. The method may beimplemented in a computing device comprising a processor, memory, andsecondary storage, such as computing device 112.

At step 1102, a placeholder for a file may be stored on the secondarystorage of the computing device. The secondary storage may be, forexample, the disk storage 124 illustrated in FIG. 1 . The files maycomprise data at least some of which is stored on a network remotelyfrom the secondary storage, such as the network (e.g., cloud) 208. Theplaceholder may be generated by the storage virtualization filter 204and may appear to a user or application as a regular file or directoryon the computing device. However, the placeholder may not contain all oreven any of the data of the file or directory. For example, the storagevirtualization provider 202 may store all or at least some of the dataassociated with the file in the remote network. Each of the placeholdersmay comprise a sparse data stream containing none or some data of thefile and information which enables the remotely stored data of the fileto be retrieved from the network.

At step 1104, a request to store metadata associated with the file maybe received. The request to store metadata associated with the file maybe received, for example, by the storage virtualization filter 204 fromthe shell 210. Or, in some embodiments, the request may be receiveddirectly from an application or other module running on the computingdevice, such as the storage virtualization provider 202. The storagevirtualization filter 204 may create and manage the placeholders for thefiles and directories, as well as metadata associated with the files anddirectories, and may notify the user-mode storage virtualizationprovider 202 of access attempts to the files or directories whose datais managed by the filter 204 and provider 202.

At step 1106, the metadata may be stored by the storage virtualizationfilter 204 in a secondary data stream of the placeholder for the givenfile. The metadata may be stored in the secondary data stream as aBinary Large Object (BLOB). A BLOB may be a collection of binary data(e.g., images, audio or other multimedia objects) stored as a singleentity. In one example, the secondary data stream of the placeholder forthe given file may hold a plurality of BLOBs, each containing differentmetadata associated with the file. Each BLOB may store a particular typeof metadata.

An example illustration of a secondary data stream of a placeholder inwhich one or BLOBs may be stored is shown in FIG. 12 . The secondarydata stream may be named based, for example, on one or morecharacteristics of the secondary data stream. The secondary data streammay have properties similar to those of a primary data stream. Forexample, read and write operations of the secondary data stream may beperformed using the same data stream APIs used for the primary datastream. As shown in FIG. 9 , the secondary data stream may comprise aheader for storing information about the secondary data stream and theone or more BLOBs stored in the secondary data stream. For example, afirst portion of the header may comprise general information about thesecondary data stream, such as the size of the data stream, the locationof certain characteristics of the data stream, etc. The header of thesecondary data stream may further comprise information about each of theone or more BLOBs stored in the secondary data stream. After the header,the secondary data stream may further comprise a property region forstorage of the one or more BLOBs. When more than one BLOB is stored on adata stream, the BLOBs may be offset from one another such that thecontent of the BLOBs does not overlap. There may also be empty spacebetween BLOBs to allow for growth of one or more of the BLOBs. One ormore of the BLOBs may also be compressed using a variety of compressionalgorithms in the secondary data stream in order to save space. Theoffset and compression properties of the one or more BLOBs in thesecondary data stream may be stored in the header in the form of anindex, each BLOB having its own entry in the index that specifies theoffset of that BLOB (e.g., in bytes) within the secondary data streamand optionally also any other properties of the BLOB, such as anycompression properties. Additionally or alternatively, the offset andcompression information may be stored within the BLOB itself.

The storage virtualization filter 204 illustrated in FIG. 4 may performthe storage of the one or more BLOBs. However, the storagevirtualization filter 204 may not be aware of the properties containedwithin the BLOBs. In other words, the properties of the BLOBs may beopaque to the storage virtualization filter 204. In one embodiment, thestorage virtualization filter 204 may simply be aware that there is aBLOB of a certain size with opaque properties, and that some higherlevel entity (e.g., the shell 210) is acting to store this BLOB or toretrieve this BLOB from the secondary storage.

As further shown in FIG. 4 , the shell 210 may be run in the user modeof the computing device 112. The shell 210 may facilitate communicationbetween an application 130 or the storage virtualization provider 202and the storage virtualization filter 204 running in the kernel mode ofthe computing device 112. For example, the shell 210 may expose an APIto at least one of the application 130 or the storage virtualizationprovider 202 to allow the application or storage virtualization providerto communicate with the storage virtualization filter 204. In oneembodiment, the shell 210 may call a storage virtualization filter APIto instruct the storage virtualization filter 204 to store the one ormore BLOBs in the secondary storage, such as the disk storage 124. Theshell 210 may be capable of accessing the properties of the one or moreBLOBs.

FIG. 13 illustrates an example method 1300 implemented by the shell 210for the storage virtualization of files. The shell may expose anapplication program interface (API) for use by at least one of anapplication or a storage virtualization provider for the storage ofmetadata in the secondary storage of the computing device. The secondarystorage may have stored thereon a placeholder for a file, the filecomprising data at least some of which is stored on a network remotelyfrom the secondary storage. The placeholder may comprise a sparse datastream containing none or some data of the file and information whichenables the remotely stored data of the file to be retrieved from thenetwork.

At step 1302, the shell 210 may receive a request to set one or moreproperties of the file. For example, the shell 210 may receive a requestfrom at least one of an application 130 or the storage virtualizationprovider 202 to set properties that are part of the metadata of thefile, such as a time stamp or a size of the file. Additionally oralternatively, the shell 210 may receive a request from at least one ofan application 130 or the storage virtualization provider 202 to setproperties that can be obtained by reading the contents of the fileitself, such as an artist or track length in an example that the file isa music file. In one embodiment, in which the underlying operatingsystem of the computing device is a WINDOWS operating system availablefrom Microsoft Corporation, the request to set one or more properties ofa file may be received in the form of a method call to an iPropertyStore interface supported by the operating system.

At step 1304, the shell 210 may combine the one or more properties intoa Binary Large Object (BLOB) and, at step 1306, the shell 210 may send,to a file system configured to manage the storage of files on thesecondary storage, a request to store the BLOB in the placeholder forthe given file. In one example, the request to store the BLOB in theplaceholder for the given file may comprise a request to store the BLOBin a secondary data stream of the placeholder for the given file.

A BLOB may be associated with a BLOB identifier so that the shell 210may associate certain properties with the BLOB based on the BLOBidentifier. In one embodiment, the BLOB identifier may be assigned tothe BLOB by one of the shell 210 or the storage virtualization filter204. The identifier may be a number, such as a 32 bit integer. In oneembodiment, the identifier may be a globally unique identifier (GUID).Some of those bits may be reserved for the placement of “flags” that mayinfluence certain behaviors of the storage virtualization filter 204.For example, a given flag may indicate that the BLOB may only be storedon a placeholder and never on a non-placeholder file. Thus, if thatplaceholder ever gets converted to a non-placeholder file (e.g., throughhydration of the file), the storage virtualization filter 204 may deletethe BLOB with the placeholder only flag.

In one embodiment, an application or the storage virtualization provider202 may be configured to communicate with the shell 210 to set orretrieve property values of the one or more BLOBs. In this example, therequest to store metadata associated with a given file may originate inthe application or the storage virtualization provider 202. Theapplication or the storage virtualization provider 202 may be aware ofthe specific properties of the file. In order to set property values fora given BLOB, the application or the storage virtualization provider 202may send a message to the shell 210 requesting that the shell set theproperties on the file. In one embodiment, this request may take theform of an IProperty API from the application or storage virtualizationprovider to the shell. The shell 210 may then form a BLOB that holdsthose property values and call a storage virtualization filter API tostore the BLOB in the placeholder for the file (e.g., in a secondarydata stream of the placeholder) on the secondary storage.

In another example, an application 130 may want to query a property of aBLOB stored in the secondary storage. For example, the application 130may be a music application that wants to query the author of a givensong file. The application 130 may communicate with the shell 210 toretrieve the requested properties from the BLOB. In response to thiscommunication, the shell 210 may retrieve the information from thestorage virtualization filter 204 using an appropriate API call to thestorage virtualization filter 204.

A number of operations may be performed on the one or more BLOBs storedwithin a placeholder for a file on the secondary storage, such asstoring, retrieving, locking, and unlocking a BLOB. However, it isunderstood that the operations are not limited to these four operations.In order to store or retrieve a BLOB, the shell 210 may call a storeproperties API or a retrieve properties API, respectively, of thestorage virtualization filter 204. For example, in response to a requestfrom an application or the storage virtualization provider to set aproperty of an existing music file, such as the name of an artist of themusic file, the shell 210 may form a BLOB containing that property andthen call the store properties API of the storage virtualization filter204 in order to have the BLOB stored in the placeholder for the file. Inorder to retrieve the metadata stored in a BLOB, the shell may call theretrieve properties API of the storage virtualization filter 204 to havethe BLOB containing that metadata retrieved from the placeholder for thefile. In one embodiment, the APIs may be used to store or retrieve twoor more BLOBs at a time. Thus, the operations may operate on a set ofBLOBs at once. If the secondary data stream has not been created by thefirst time a store or retrieve API is called, the storage virtualizationfilter 204 may be configured to automatically create the secondary datastream.

The store properties API may be used to update an existing BLOB storedin an alternate data stream. When the store properties API is called tostore a BLOB having the same unique identifier as an existing BLOB, theentirety of the existing BLOB may be overwritten with the new BLOB, thuseffectively updating it. However, the BLOB identifier may remainunchanged. The store properties API may also be used to delete anexisting BLOB. To delete an existing BLOB, the shell may call the storeproperties API with the identifier of the BLOB to be deleted and anindication that the BLOB has a length of 0. When such a store propertiesAPI call is received, the storage virtualization filter 204 will deletethe BLOB. Thus, with the same store properties API, a BLOB may be added,updated, or deleted from the secondary data stream of a placeholder. Theretrieve properties API may not modify the secondary data stream at all.

In addition to the shell, other applications, modules, or components mayalso be able to store, retrieve, update, and retrieve stored BLOBs also.If the shell or an application, for example, wants to perform a seriesof operations on a particular BLOB and does not want other applicationsto be able to read that BLOB or make modifications to that BLOB, theapplication may lock the BLOB using a lock properties API. A givenapplication may lock multiple BLOBs using a single lock properties APIcall. In one embodiment, there may be two types of locks available to anapplication: an “exclusive lock” and a “shared lock.” An exclusive lockmay give the application exclusive access to the BLOB until theapplication calls an unlock properties API. No other applications may beable to read or make modifications to the BLOB while a particularapplication has locked the given BLOB. On the other hand, a shared lockmay allow multiple applications to lock a given BLOB at the same time.Thus, application A may be able to request a shared lock on a BLOB eventhough the BLOB has already been locked by application B. In oneembodiment, a shared lock may allow any subsequent lockers to read theBLOB but may not allow the subsequent lockers to make edits. Thus, inthe example above, application A may be able to read the properties ofthe BLOB but may not be able to make changes to the BLOB. In anotherexample, no applications may be able to make modifications to the BLOBwhile the BLOB is under a shared lock. In yet another example, two ormore applications may agree on a set of rules regarding read and writeoperations to a BLOB under the shared lock. If an application attemptsto acquire a lock on multiple BLOBs at once, and one of the BLOBs isalready under an exclusive lock, the entire lock operation may fail forall of the BLOBs. Alternatively, the application may be granted a lockon only the BLOBs that are not under an exclusive lock. The storagevirtualization filter 204 may be aware of the specific application thathas locked a particular BLOB since the storage virtualization filter 204is the component in charge of the store and retrieve operations.

As discussed herein, an application 130 may communicate with the shell210 to request that individual property values be set on a file or beadded or updated in a given BLOB. The application may identify the BLOBby the BLOB identifier, such as the 32 bit integer (e.g., GUID). Theshell may then call a storage virtualization filter API, such as thestore properties API, to store the BLOB in the secondary data stream.The storage virtualization filter 204 may then store the BLOB in thesecondary data stream. In another example, the application may wish toretrieve an individual property of a given BLOB. The application maycommunicate with the shell to call a storage virtualization filter API,such as the retrieve properties API, causing the storage virtualizationfilter to find that BLOB in the secondary data stream and pass thecontents of the BLOB to the shell. The shell may then retrieve therequested property and return it to the application.

In one embodiment, an application may want to modify a property valuestored in an existing BLOB. The shell may determine that the particularvalue in the BLOB needs to be updated but that there are otherproperties in the BLOB that must be left alone. In order to addressthis, the shell may acquire an exclusive lock on the BLOB being changed.The shell may then call a retrieve properties API to read the propertiesof the BLOB into the shell's memory. The shell may then decode the BLOBso that it knows all of the individual values of the BLOB. The shell maychange the property requested by the application to be modified, but mayleave all other property values stored in the BLOB unchanged. The shellmay then re-encode this set of values into a new BLOB and may call thestore properties API to store the new BLOB in the secondary storage.However, the shell will use the same identifier for the new BLOB as theoriginal BLOB. The storage virtualization filter 204 may then overwritethe old BLOB, and the shell 210 may call the unlock properties API tounlock the BLOB.

The shell 210 may be configured to sort the one or more BLOBs based onthe type of BLOB. In one embodiment, there may be two types of BLOBs inthe secondary storage: a storage virtualization provider supplementalproperties BLOB and a file format properties BLOB. The storagevirtualization provider supplemental properties BLOB may compriseproperties that are generated by or provided by a storage virtualizationprovider 204—and for which the storage virtualization provider may makea request to the shell to store in associate with a file that thestorage virtualization provider is managing on remote storage. Theseproperties may be properties that describe the file in the context ofthe storage virtualization provider, such as whether the file is checkedout, who last modified the file, and whether the file is shared betweentwo or more users. In contrast, the file format properties BLOB maycontain information that is derivable from the contents of the fileitself. In an example that the file is a music file, the file formatproperties BLOB may store metadata about the artist, number of tracks,the length of each track, and the like. When the file later fullyhydrated, the file format properties BLOB may no longer be needed sincethe contents of the file may be present on the computing device. Thus,when the file is fully hydrated, the file format properties BLOB may bedeleted since it would make more sense to use the most up to dateinformation. However, any storage virtualization provider supplementalproperties BLOB may remain intact. It is understood that other types ofBLOBs may be included as well. In one embodiment, a third category ofBLOB may allow an application to add metadata that describes a file. Forexample, if the application is a photograph application that can performface recognition, the application may be able to store the namesassociated with the detected faces as metadata in the BLOB.

The BLOB may be formatted in any number of ways. In one embodiment, aproperties store may identify certain properties of the BLOB using, forexample, a globally unique identifier (GUI). However, unknown propertiesmay also be stored. These properties may have a value that can be almostany serializable type (e.g., string, Boolean, signed/unsigned integers,etc.). The properties may be serialized into an internal format and thendeserialized upon being read. As discussed herein, the BLOB may also becompressed to save room in the secondary storage.

The illustrations of the aspects described herein are intended toprovide a general understanding of the structure of the various aspects.The illustrations are not intended to serve as a complete description ofall of the elements and features of apparatus and systems that utilizethe structures or methods described herein. Many other aspects may beapparent to those of skill in the art upon reviewing the disclosure. Forexample, while the methods and system discussed herein have been appliedto the use of placeholders in a storage virtualization system, it isunderstood that the methods and systems may be used for any number ofpurposes. Other aspects may be utilized and derived from the disclosure,such that structural and logical substitutions and changes may be madewithout departing from the scope of the disclosure. Accordingly, thedisclosure and the figures are to be regarded as illustrative ratherthan restrictive.

The various illustrative logical blocks, configurations, modules, andmethod steps or instructions described in connection with the aspectsdisclosed herein may be implemented as electronic hardware or computersoftware. Various illustrative components, blocks, configurations,modules, or steps have been described generally in terms of theirfunctionality. Whether such functionality is implemented as hardware orsoftware depends upon the particular application and design constraintsimposed on the overall system. The described functionality may beimplemented in varying ways for each particular application, but suchimplementation decisions should not be interpreted as causing adeparture from the scope of the present disclosure.

The various illustrative logical blocks, configurations, modules, andmethod steps or instructions described in connection with the aspectsdisclosed herein, or certain aspects or portions thereof, may beembodied in the form of computer executable instructions (i.e., programcode) stored on a computer-readable storage medium which instructions,when executed by a machine, such as a computing device, perform and/orimplement the systems, methods and processes described herein.Specifically, any of the steps, operations or functions described abovemay be implemented in the form of such computer executable instructions.Computer readable storage media include both volatile and nonvolatile,removable and non-removable media implemented in any non-transitory(i.e., tangible or physical) method or technology for storage ofinformation, but such computer readable storage media do not includesignals. Computer readable storage media include, but are not limitedto, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM,digital versatile disks (DVD) or other optical disk storage, magneticcassettes, magnetic tape, magnetic disk storage or other magneticstorage devices, or any other tangible or physical medium which may beused to store the desired information and which may be accessed by acomputer.

Although the subject matter has been described in language specific tostructural features and/or acts, it is to be understood that the subjectmatter defined in the appended claims is not necessarily limited to thespecific features or acts described above. Rather, the specific featuresand acts described above are disclosed as examples of implementing theclaims and other equivalent features and acts are intended to be withinthe scope of the claims.

The description of the aspects is provided to enable the making or useof the aspects. Various modifications to these aspects will be readilyapparent, and the generic principles defined herein may be applied toother aspects without departing from the scope of the disclosure. Thus,the present disclosure is not intended to be limited to the aspectsshown herein but is to be accorded the widest scope possible consistentwith the principles and novel features as defined by the followingclaims.

What is claimed is:
 1. A method for managing metadata associated with afile, the method comprising: storing, on storage of a computing device,a placeholder for a file that comprises information that enablesretrieval of remotely stored data of the file; receiving a request tostore metadata associated with the file; storing the metadata in asecondary data stream of the placeholder with a flag indicating that themetadata is to be deleted when the placeholder is converted to a regularfile; retrieving the remotely stored data of the file; converting theplaceholder to the regular file by storing, on the storage, the remotelystored data in a primary data stream for the file; and deleting themetadata in response to the placeholder being converted to the regularfile.
 2. The method of claim 1, wherein the metadata is stored in thesecondary data stream as a Binary Large Object (BLOB).
 3. The method ofclaim 2, wherein the secondary data stream comprises a plurality ofBLOBs, each BLOB comprising a different type of metadata associated withthe file.
 4. The method of claim 3, wherein the secondary data streamcomprises a header for storing information about the plurality of BLOBs.5. The method of claim 2, wherein a property contained within the BLOBis opaque to a file system of the storage.
 6. The method of claim 2,further comprising: receiving, from an application, a request to lockthe BLOB; and locking, in response to the request, the BLOB, therebyproviding, to the application, exclusive access to the BLOB.
 7. Themethod of claim 1, wherein the request to store metadata is receivedfrom one of an application or a storage virtualization provider thatmanages the remotely stored data.
 8. A method, comprising: receiving arequest to set a property of a file that is stored remotely from thestorage, wherein a placeholder for the file is stored on the storage andthe placeholder comprises information that enables retrieval of remotelystored data of the file; generating a Binary Large Object (BLOB)comprising the property of the file; and sending, to a file system ofthe storage, a request to store the BLOB in the placeholder for thefile, the BLOB having an associated flag indicating whether the BLOB isdeleted when the placeholder is converted to a regular file.
 9. Themethod of claim 8, wherein the request to set the property of the fileis received from one of an application or a storage virtualizationprovider.
 10. The method of claim 8, wherein the request to store theBLOB in the placeholder for the file comprises a request to store theBLOB in a secondary data stream of the placeholder for the file.
 11. Themethod of claim 10, wherein the secondary data stream of the placeholdercomprises a plurality of BLOBs, each BLOB comprising a different type ofmetadata associated with the file.
 12. The method of claim 10, whereinthe secondary data stream comprises a header for storing informationabout the BLOB.
 13. The method of claim 8, further comprising sending,to the file system, a request to retrieve a property of the BLOB. 14.The method of claim 8, wherein the BLOB is one of a synchronizationsupplemental properties BLOB or a file format properties BLOB.
 15. Acomputing device comprising: a processor; storage; and memory storingcomputer-executable instructions that, when executed by the processor,implement a file system for managing storage of files on the storage,the file system being configured to perform operations comprising:storing, on the storage, a placeholder for a file that comprisesinformation that enables retrieval of remotely stored data of the file;receiving a request to store metadata associated with the file; storingthe metadata in a secondary data stream of the placeholder with a flagindicating whether the metadata is permitted to be retained when theplaceholder is converted to a regular file; retrieving the remotelystored data of the file; storing, on the storage, the remotely storeddata in a primary data stream for the file, thereby converting theplaceholder to the regular file; and determining, based on the flag, todelete the metadata from the secondary data stream in response to theplaceholder being converted to the regular file.
 16. The computingdevice of claim 15 wherein the metadata is stored in the secondary datastream as a Binary Large Object (BLOB).
 17. The computing device ofclaim 16, wherein the secondary data stream comprises a plurality ofBLOBs, each BLOB comprising a different type of metadata associated withthe file.
 18. The computing device of claim 17, wherein the secondarydata stream further comprising a header storing information about theplurality of BLOBs
 19. The computing device of claim 16, wherein aproperty contained within the BLOB is opaque to the file system.
 20. Thecomputing device of claim 15, wherein the request to store metadata isreceived from one of an application or a storage virtualization providerthat manages the data of the file that is stored remotely on thenetwork.